32 Bit generic bus interface using read/write byte enables

ABSTRACT

A display controller configured to communicate with a microprocessor is provided. The display controller includes a memory core for storing image data to be displayed and a register set containing configuration data enabling presentation of the image data. A bus interface enabling communication over a bus between the memory core of the display controller and the microprocessor is included. The bus interface is configured to communicate with a set of command signals. The set of command signals defines both whether read operations and write operations are to occur over a bus cycle and whether valid data exists for each bit of the read operation and the write operation. Each command signal in the set of command signals defines enable data for the read operations or write operations. A system including the display controller and methods for adapting the display controller to communicate with a variety of microprocessors are also included.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] This invention relates generally to computer systems and moreparticularly to a generic bus interface capable of communicating with avariety of microprocessors.

[0003] 2. Description of the Related Art

[0004] Portable consumer electronic devices are pervasive in all aspectsof society today. Examples of such devices include personal digitalassistants (PDA), mobile phones, pagers, web tablets, etc. Theseportable devices contain embedded systems that include centralprocessing units (CPU). Due to the narrow range of functions provided bythese handheld devices, the CPUs associated with these embedded systemsare not required to have as powerful computing power as desktop orlaptop CPUs. A number of vendors provide CPUs designed specifically fora type of handheld device. As is well known, the CPUs also includenative buses that support the CPUs. Additionally, the devices include adisplay screen where images are presented under the control of a displaycontroller, such as a liquid crystal display (LCD) controller. Thedisplay controller, typically manufactured by a vendor different fromthe CPU vendor, is customized to include a bus interface that allows thedisplay controller to communicate with specific CPUs through a systembus. Because of the wide variety of the CPUs, the display controllerstend to be customized to interface with a narrow range of CPUs.

[0005]FIG. 1 is a schematic diagram of an embedded system including aCPU in communication with a LCD controller. CPU 100 communicates throughbus 102 to bus interface 104 of LCD controller 106. The brand of CPU 100and type of bus 102 dictates the requirements for the bus interface 104of LCD controller 106. Thus, bus interface 104 of LCD controller 106 iscustomized for the different types of buses and CPUs on the market. Thecustomization requires LCD controllers with different bus interfaces foreach of the different types of buses and CPUs.

[0006] Since there are a large variety of CPUs supplied from vendorssuch as Motorola, Hitachi, Intel, etc. for the portable devices,customization of the display controller's bus interface becomes anexpensive proposition to support each of the available microprocessorsand their native bus interfaces. That is, different bus interfaces foreach CPU must be supported by the supplier of the LCD controller. Sinceeach of the native bus interfaces will have different pins as well asdifferent signals to be accommodated, the management of which interfaceis associated with which CPU becomes a difficult task. Accordingly, theLCD chip is more complex and less flexible through the customizationrequired by this approach.

[0007] The portable consumer electronic devices incorporating the LCDcontroller are designed to consume low amounts of power since thedevices are typically battery powered. In addition, size is constantlybeing reduced as the devices are designed with portability in mind.Thus, it is not practical to simply combine the different bus interfaceswith one LCD controller because of the multitude of interfacesavailable. That is, if all the bus interfaces were simply added to theLCD controller, the LCD would have a huge pin count for accommodating alarge number of signals. As a result, the size of the LCD controllerwould be prohibitive and the power consumption would increase if eachbus interface was simply added to the LCD controller.

[0008] As a result, there is a need to solve the problems of the priorart to provide an LCD controller with a generic bus interface having theflexibility of communicating with a variety of microprocessors withoutcomplicating the chip architecture or increasing the size of thecontroller.

SUMMARY OF THE INVENTION

[0009] Broadly speaking, the present invention fills these needs byproviding a generic bus interface configured to be compatible with avariety of microprocessors and their native buses. It should beappreciated that the present invention can be implemented in numerousways, including as a process, a system, or a device. Several inventiveembodiments of the present invention are described below.

[0010] In one embodiment a display controller configured to communicatewith a microprocessor is provided. The display controller includes amemory core for storing image data to be displayed and a register setcontaining configuration data enabling presentation of the image data. Abus interface enabling communication over a bus between the memory coreof the display controller and the microprocessor is included. The businterface is configured to communicate with a set of command signals.The set of command signals defines both whether read operations andwrite operations are to occur over a bus cycle and whether valid dataexists for each bit of the read operation and the write operation. Eachcommand signal in the set of command signals defines enable data for theread operations or write operations.

[0011] In another embodiment, a system having a display controller witha generic bus interface is provided. The system includes a centralprocessing unit (CPU) and a data bus. A display controller incommunication with the CPU through the data bus is included. The displaycontroller includes a bus interface enabling communication over the databus with the CPU. The bus interface is configured to communicate with aset of command signals. The set of command signals defines both whetherread operations and write operations are to occur over a bus cycle andwhether valid data exists for each bit of the read operation and thewrite operation. Each command signal in the set of command signalsdefines enable data for the read operations or the write operations.

[0012] In yet another embodiment, a method for performing a readoperation or a write operation between a microprocessor and a displaycontroller is provided. The method initiates with a set of commandsignals being defined. The set of command signals is configured toindicate whether the read operation or the write operation is to beperformed over a bus cycle and whether valid data exists for each bit ofthe read operation and the write operation. Each command signal in theset of command signals defines enable data for one of the readoperations and write operations. Then, a display controller incommunication with a system bus is selected. Next, the set of commandsignals are asserted. Then, the asserted set of command signals aresampled to determine a type of operation and a bit-location of validdata on the system bus. Next, the bit location of the system bus havingthe valid data is selected. Then, the read operation or write operationis performed.

[0013] In still yet another embodiment, a method for adapting a displaycontroller to communicate with a variety of microprocessors is provided.The method initiates with a chip select signal being received. Then, thechip select signal is acknowledged. Next, a set of command signals isreceived. The set of command signals is configured to indicate whetherthe read operation or the write operation is to be performed over a buscycle and whether valid data exists for each bit of the read operationand the write operation. Each command signal in the set of commandsignals defines enable data for the read operations or write operations.Then, the read or the write operation is performed for the valid data asdefined by the command signals.

[0014] Other aspects and advantages of the invention will becomeapparent from the following detailed description, taken in conjunctionwith the accompanying drawings, illustrating by way of example theprinciples of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The present invention will be readily understood by the followingdetailed description in conjunction with the accompanying drawings, andlike reference numerals designate like structural elements.

[0016]FIG. 1 is a schematic diagram of an embedded system including aCPU in communication with a display controller, such as a LCDcontroller.

[0017]FIG. 2 is a high level schematic diagram of a LCD controller witha generic bus interface in communication with a CPU in accordance withone embodiment of the invention.

[0018]FIG. 3 is a table illustrating the command signals that determinewhether the current bus cycle is a read or a write cycle and thelocation of valid data on the bus in accordance with one embodiment ofthe invention.

[0019]FIG. 4 is a timing diagram for a generic bus interface associatedwith the command signals that determine whether the current bus cycle isa read or a write cycle and to determine a location of valid data on thebus in accordance with one embodiment of the invention.

[0020]FIG. 5 is a table listing the bus interface timing parametersassociated with FIG. 4.

[0021]FIG. 6 is a table illustrating the command signal encoding thatutilizes two sets of control signals to determine whether the currentbus cycle is a read operation or a write operation and the location ofvalid data on the bus in accordance with one embodiment of theinvention.

[0022]FIG. 7 is a timing diagram for a generic bus interface usingseparate control signals and enable signals, as discussed with referenceto FIG. 6, to define a bus cycle in accordance with one embodiment ofthe invention.

[0023]FIG. 8 is a table representing the bus interface timing parametersassociated with FIG. 7.

[0024]FIG. 9 is a table illustrating the command signal encoding for anasynchronous generic bus interface that determines whether the currentbus cycle is a read or a write cycle and the location of valid data onthe bus in accordance with one embodiment of the invention.

[0025]FIG. 10 is a timing diagram of an asynchronous generic businterface of a display controller configured to support any differencein clock speed between the display controller and a CPU in communicationwith the display controller in accordance with one embodiment of theinvention.

[0026]FIG. 11 is a table representing the asynchronous bus interfacetiming parameters of FIG. 10.

[0027]FIG. 12 is a schematic diagram of flip flop chain redundancycircuitry configured to minimize the occurrence of any metastablecondition in accordance with one embodiment of the invention.

[0028]FIG. 13 is a flowchart diagram illustrating the method operationsfor communicating between a display controller operating at a firstclock speed and a microprocessor operating at a second clock speed inaccordance with one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] An invention is described for an apparatus and method forproviding a generic bus interface for a controller that is adapted tocommunicate with a variety of central processing units (CPU). It shouldbe appreciated that the various signals processed through the businterface are referred to herein as an abbreviation for the signalfollowed by the “#” symbol. Of course, other common designations in theart for signals include an abbreviation with an over line or anabbreviation followed by the letter “X”. Additionally, logic high valuesmay be referred to as having a binary value of “1” while a logic lowvalue may be referred to as having a binary value of “0.” It will beapparent, however, to one skilled in the art, in view of the followingdescription, that the present invention may be practiced without some orall of these specific details. In other instances, well known processoperations have not been described in detail in order not tounnecessarily obscure the present invention.

[0030] The embodiments of the present invention provide a generic businterface for a display controller in communication with a CPU. In oneembodiment, the configuration of the command signals provided to thegeneric bus interface enables communication with a variety ofmicroprocessors and their associated native buses. As will be explainedin more detail below, the command signals are configured to define aread or write operation to be performed as well as defining a locationof valid data on the native bus. In another embodiment, the generic businterface accommodates an asynchronous exchange of data. Here, thedisplay controller and the CPU are controlled by different clocks havingdifferent clock speeds. Through the handshaking defined between the CPUand the display controller, previous limitations required due todifferences in operating speeds between the clock speeds, no longerapply.

[0031] The generic bus interface described herein, is capable ofcommunicating with a variety of CPUs, particularly the CPUs in theembedded market, which include processors from HITACHI, MOTOROLA, INTEL,etc. As is well known, embedded systems define microprocessor basedelectronic systems that perform an application-specific set offunctions. Embedded systems tend to be dedicated to sensing andresponding to input. One skilled in the art will appreciate that theembedded systems exist in many industries, including automotive,communications, consumer and industrial. More specifically, embeddedsystems are used with compact portable handheld devices, such aspersonal digital assistants (PDA), mobile phones, pagers, web tablets,etc. These portable handheld devices do not require the same amount ofcomputing power as a desktop or laptop computer because of theirspecific nature. Additionally, these devices consume less power than thedesktop or laptop systems because of battery power limitations.Accordingly, devices incorporating embedded systems do not provide thesame degree of functionality as desktop computer systems. While theembodiments described below are directed toward CPUs for handheldelectronic devices, these embodiments are exemplary and not meant to belimiting. It will be apparent to one skilled in the art that the genericbus interface can be configured to communicate with CPUs for desktop andportable personal computers.

[0032] In one embodiment, the generic bus interface supports a datawidth of 32 bits addressable over 21 bits of address space. Of course,the bus interface can support a data width over any suitable number ofbits of address space. The bus interface is configured to accommodatethe signals that are necessary to attach to most CPU interfaces throughthe command signals defined below. Little and big endian modes are bothsupported by the generic bus interface. One skilled in the art willappreciate that little and big endian modes describe the order in whicha sequence of bytes are stored in memory. As described in more detailbelow, the embodiments of the bus interface include a bus interfaceconfigured to operate in a synchronous mode and a bus interfaceconfigured to operate in an asynchronous mode. In the synchronous mode,the bus cycle can be lengthened through the use of an external WAIT#control signal which can be set to active high or active low. Theasynchronous generic bus interface is configured to be independent ofthe difference between the clock speed of the display controller and theclock speed of the CPU in communication with the display controller. Inaddition, the asynchronous bus interface includes circuitry forminimizing the occurrence of a metastable condition.

[0033]FIG. 2 is a high level schematic diagram of a display controller,such as a liquid crystal display (LCD) controller with a generic businterface in communication with a CPU in accordance with one embodimentof the invention. CPU 108 is in communication with LCD controller 116through bus 112. CPU can be any number of suitable microprocessors. Inone embodiment, CPU 108 is a microprocessor designed for an embeddedsystem. One such embedded system is the HITACHI SH3 microprocessor,which includes a native bus supporting the SH3 microprocessor. It shouldbe appreciated that the HITACHI SH3 microprocessor is mentioned forillustrative purposes only and not meant to be limiting on theinvention, as LCD controller 116 includes generic bus interface 114 thatis configured to communicate with a variety of suitable CPUs of embeddedsystems and non-embedded systems. As used herein, LCD controller 116 canbe any suitable display controller that may or may not be associatedwith an embedded system.

[0034] Still referring to FIG. 2, LCD controller 116 includes memorycore region 118 and register region 120. Memory core region 118 containsthe data for an image to be presented on an LCD panel. Register region120 (also referred to as a register set) contains data to configure LCDcontroller 116, which includes configuration data for a type of displaypanel used to display the image, such as resolution, screen size, paneltype, etc. That is, the registers of the register set are programmed toallow LCD controller 116 to interface with a display screen forpresenting the image data in memory. CPU 108 contains registers that mapLCD controller 116 into CPU memory 110. Thus, when CPU memory 110 isaddressed, CPU 108 asserts a chip select signal (CS#). In oneembodiment, the CS# signal is used to notify LCD controller 116 that theLCD controller is being addressed as will be explained in more detailbelow.

[0035]FIG. 3 is a table illustrating a set of command signals thatdetermine whether the current bus cycle is a read or a write cycle andthe location of valid data on the bus in accordance with one embodimentof the invention. As will explained below, the same set of signals whichspecify the read or write cycle simultaneously specify which bytes of a32 bit data bus contain valid data. Thus, a certain bit width of the 32bit data bus, i.e., 8 bit, 16 bit, or 32 bit, is specified by the sameset of signals specifying whether the bus cycle is a read operation or awrite operation. It should be appreciated that each of the commandsignals define enable data for either the read operation or the writeoperation.

[0036] Still referring to FIG. 3, a bus cycle is initiated when a chipselect signal (CS#) is to asserted low. The assertion of one or moreread enable signals (RDn#) after the assertion of the CS# specifies aread cycle. Alternatively, the assertion of one or more write enablesignals (WEn#) after the assertion of the CS# sets a write cycle. Inaddition, the configuration of the RD# and the WE# specify which bytesof a 32 bit data bus contain valid data. That is, the read or writecycle can be further specified as a 8-bit, 16-bit or 32-bit read orwrite cycle. It should be appreciated that by accommodating 8-bit,16-bit and 32-bit reads and writes, the bus interface of a displaycontroller, such as a liquid crystal display (LCD) controller, is notprevented from communicating with a CPU requiring an interfaceaccommodating 8 bit or 16 bit reads.

[0037] Therefore, the bus interface of the display controller caninterface with a wide variety of microprocessors.

[0038] Continuing with FIG. 3, it can be seen that the CS# is activelow. For a read cycle, each of the WE# (WE#0-WE#3) are driven high toindicate a read cycle, i.e., where the LCD controller supplies data to aCPU. Alternatively, for a write cycle, each of the RD# (RD#0-RD#3) aredriven high to indicate a write cycle, i.e., where a CPU directs data tothe LCD controller. As the WE# are all high during a read, theconfiguration of the RD# signals indicate the location of valid data onthe data bus. For example, the command signal encoding for a high even 8bit read, as defined in row 121, will be explained in further detail tospecify the configuration of the command signals. Here, CS# is assertedlow indicating that the LCD controller is being selected by the CPU.WE#0-WE#3 are each asserted high to indicate that a read cycle willoccur. RD#3, RD#1 and RD#0 are asserted high while RD#2 is asserted low.This combination indicates that valid information is contained over bits15-23 of the data bus. Thus, the command signals of row 121 define ahigh even 8 bit read bus cycle. It should be appreciated that one set ofcommand signals define both whether a read operation or a writeoperation is to be performed and a location of valid data on the databus through which the display controller and the CPU communicate. Thatis, one command signal is used for each 8 bit segment for either a reador write operation.

[0039] Additionally, each of the command signals of FIG. 3 define enabledata for a read operation or a write operation. Thus, WE#0-WE#3 defineenable data for a write operation while RD#0-RD#3 define enable data fora read operation. Consequently, the bus interface is capable ofperforming on command modifiable reads and writes to accommodate a broadvariety of CPUs. That is, the bus interface is not limited to a 32 bitread operation, therefore, the bus interface is capable of communicatingwith a CPU interface requiring an 8 bit, 16 bit or 32 bit read. Itshould be appreciated that the set of command signals may be definedwith the logical high and low values, illustrated in FIG. 3, reversed.

[0040]FIG. 4 is a timing diagram for a generic bus interface associatedwith the command signals that determine whether the current bus cycle isa read or a write cycle and determine a location of valid data on thebus in accordance with one embodiment of the invention. Bus clock period(TCLK) is indicative of the system speed for the bus clock (CLK). Forexemplary purposes, the LCD controller includes 21 bits of addressspace, as represented by A[20:0], which determines the amount of memorywithin the LCD controller. It will be apparent to one skilled in the artthat the amount of address space of the LCD controller may vary. In oneembodiment, the LCD controller has about 2 Megabytes (MB) of memory.That is, 21 bits of address space maps out to about 2 MB of memory. Thememory inside the LCD controller is addressed through address linesA[20:0]. One skilled in the art will appreciate that the LCD controllercan contain any amount of memory suitable for the system containing theLCD controller and is not limited to 2 MB of memory. Memory/Registersignal (M/R#) is a signal that selects between memory (M) and registers(R) of the LCD controller. In one embodiment, an additional 2 MB ofmemory is provided through the M/R# pin. As mentioned above, the memorycore contains image data to be presented while the registers includeconfiguration data, such as the configuration data for the displayscreen where the data is to be displayed. It will be apparent to oneskilled in the art that the bus interface described in reference to FIG.4 is a synchronous bus interface as the CPU and the display controllershare a common clock.

[0041] Referring to FIG. 2, CPU 108 includes registers that map LCDcontroller 116 into memory 110 of the CPU. Thus, when CPU memory 110 isaddressed, the CPU 108 asserts a CS# low which tells LCD controller 116that the LCD controller is being selected. Of course, the CS# signal canbe asserted low or high to indicate that LCD controller 116 is beingselected. Returning to FIG. 4, the signals are sampled on the risingedge of the clock, however, it will be apparent to one skilled in theart that the signals can be sampled on the falling edge of the clock.When sampling signals on the rising edge of the clock, parameter t2indicates a set up time for the bus clock to see the CS# go low. Theconfiguration of command signals, WE0#, WE1#, WE2#, WE3#, RD0#, RD1#,RD2# and RD3#, indicates a type of access, i.e., read operation or awrite operation. For example, with reference to FIG. 3, a command signalwhere RD3# is 0 (low) and the remaining read and write signals are 1(high) indicates that the type of access is a high odd 8-bit read.Accordingly, data bits 31 through 24 of the bus are selected as thesebits have valid data on them as defined by the command signals. Thus,the CPU samples bits 31-24 of the data bus during the read operation.

[0042] Parameter t1 of FIG. 4 represents a set up time for the LCD chipto see the CS# go low and to determine if a read operation or writeoperation is to occur through the configuration of the WE# or the RD#.It will be apparent to one skilled in the art that the set up timeensures that CS# will be sampled in the desired state. Set up time t3allows a window for the read and write command signals to be assertedbefore the display controller samples the read and write commandsignals. For exemplary purposes, command signals configured to define alow even 8 bit read operation, as specified in row 123 of FIG. 3, willbe referenced to further explain the timing diagram of FIG. 4 withreference to a read operation. Furthermore, it will be apparent to oneskilled in the art that the set up and hold times referred to hereinaccommodates a propagation delay from when a high or low signal issampled to when a next action occurs based on the high or low signal.

[0043] Still referring to FIG. 4, when CS# goes low, a wait signal(WAIT#) is driven low within timing parameter t4, as indicated by arrow126. WAIT# is output from the display controller, such as a LCDcontroller, to the CPU and requests that the CPU wait until the LCDcontroller is ready to supply data. One skilled in the art willappreciate that for a read operation, the LCD controller is supplyingdata to the CPU. While WAIT# is low, the CPU extends the cycle until theLCD controller is ready to supply the data. Thus, the CPU will continuesampling the WAIT# and extending the cycle until WAIT# goes high. WAIT#goes high when valid data has been put onto the bus as indicated byarrow 128. On the rising edge of the bus clock, the CPU will sample theWAIT# and see that WAIT# has gone high, therefore, the CPU can read thedata contained over bits 0-7 for the low even 8-bit read specified bythe command signals. The valid data is supplied to the CPU during timingparameter t13 of the read cycle. As mentioned above, the CPU or the LCDcontroller can be configured to sample on the falling edge of the clockcycle rather than the rising edge.

[0044] Continuing with FIG. 4, timing parameter t5 of the read cycledefines a time period within which the LCD controller will drive thedata bus. Dark envelope 122 indicates that the LCD controller is drivingthe data bus, thereby preventing another controller from taking over thebus. The dark envelopes of FIG. 4 represent that valid data is notavailable while the light envelopes represent that valid data isavailable. Thus, valid read data becomes available at some point withinlight envelope 124. Timing parameter t16 provides a set up time for theWAIT# to go high in order for the CPU to read the data. Therefore,during timing parameter t13 data is transferred, i.e., the CPU latchesthe data, as the rising edge of the bus clock occurs with the WAIT#high. It should be appreciated that within timing parameter t11, WAIT#is driven to a high impedance state where control of the bus isrelinquished by the LCD controller for use by other devices.

[0045] For a write operation, with reference to FIG. 4, the CPU isdirecting data over the bus to the LCD controller. The CS# is driven lowas mentioned above and is sampled by the LCD controller. Set up time t3allows a window for the read and write command signals to be assertedbefore the LCD controller samples the read and write command signals.The configuration of the read and write command signals will indicatethe type of access. For exemplary purposes, the 32-bit write of FIG. 3will be used to describe an exemplary write operation. That is, commandsignals WE0#, WE1#, WE2#, and WE3# are all low (0 values) while RD0#,RD1#, RD2# and RD3# are all high (1 values). Therefore, all 32 bits onthe data bus are valid. At the same time that the read and write commandsignals are sampled, the address will be sampled to determine where thedata is being addressed in the memory core of the LCD. For a writeoperation, the CPU drives the read enable signals high. As mentionedabove, for the 32-bit write all four write enable signals (WE0#-WE3#)are driven low indicating that all 32 bits on the data bus are valid.The WAIT# is driven low to extend the bus cycle until valid data isavailable. Timing parameter t6 defines a set up period within which theCPU must drive the data on the data bus. WAIT# is held low until the LCDcontroller is ready to receive data at which point WAIT# is driven high.When WAIT# is driven high, the data is sampled and latched in by the LCDcontroller.

[0046] Still referring to FIG. 4, timing parameter t12 is a hold time.As mentioned above, there is some propagation delay between the samplingof a signal and the action resulting from the sampling. Thus, t12 is ahold time defining a time period for data to be held after the LCDcontroller is ready to receive the data, i.e., the WAIT#. Driving WAIT#high signifies that data has been written. Similar to the readoperation, once WAIT# has been deasserted (driven high), the CPU endsthe cycle by deasserting the read or write strobe as indicated by line130. Additionally, the CPU deasserts the CS#, by driving CS# high asindicated by line 132. Timing parameter t9 represents the time periodbetween the WAIT# being deasserted and the read cycle or write cyclebeing deasserted.

[0047]FIG. 5 is a table listing the timing parameters associated withFIG. 4. Timing parameters t1-6, t9, t11-13 and t16 are discussed abovewith respect to FIG. 4. Timing parameter t7 represents a time periodrequired to keep the current cycle active, i.e., CS# low, after the CPUdeasserts the command signals. The minimum time for parameter t7 is zeronanoseconds (ns), however, one skilled in the art will appreciate thatmost CPUs do not deassert CS# until one or two clocks after the commandsignals are deasserted. Thus, the LCD controller is capable of handlingconcurrent deassertion of the command signals and CS# from the CPU, aswell as deassertion of CS# after the command signals are deasserted.Timing parameter t8 represents a time period for which the CS# isdeasserted (held high). At the end of time period t8, the CS# signal isreasserted, thereby signifying to the LCD controller that it has beenselected for another read or write operation. Timing parameter t10indicates a time period from which the command signals are deasserted toa point where the command signals are reasserted for another read orwrite operation. Time period t14 represents the length of a cycle for aread or write operation. Timing parameter t15 signifies a time periodbetween the rising edge of the bus clock and the WAIT# being drivenhigh. It should be appreciated that the timing parameters are exemplarytiming periods and that the actual time period associated with eachtiming parameter can be any suitable time period allowing each operationto be accomplished.

[0048]FIG. 6 is a table illustrating the command signal encoding thatutilizes two sets of control signals to determine whether the currentbus cycle is a read operation or a write operation and the location ofvalid data on the bus in accordance with one embodiment of theinvention. The command signals of FIG. 6 are all active low. A chipselect signal (CS#) is driven low to indicate that the LCD controllerhas been selected. The assertion of the read control signal (MEMR#)indicates a read cycle while the assertion of the write control signal(MEMW#) indicates a write cycle. It should be appreciated that the MEMR#and MEMW# have no effect on the determination of which parts of the databus contain valid data. That is, the MEMR# and MEMW# do not includeenable data corresponding to the data associated with the read operationor the write operation. Four byte enable signals (BE#) are used tospecify which bytes of a 32 bit data bus contains valid data. Thus, an 8bit, 16 bit or 32 bit read bus cycle or write bus cycle can be specifiedas indicated by the various combinations of BE0#-BE3#.

[0049]FIG. 7 is a timing diagram for a generic bus interface usingseparate control signals and enable signals, as discussed with referenceto FIG. 6, to define a bus cycle in accordance with one embodiment ofthe invention. The bus interface supports a data width of 32 bitsaddressable over 21 bits of address space. As mentioned previously, thebus interface is not limited to 21 bits of address space as 21 bits ofaddress space is shown here for exemplary purposes only. One skilled inthe art will appreciate that the bus interfaces described herein canhave up to 32 bits of address space. Little and big endian modes areboth supported by the bus interface. A bus cycle starts with the chipselect signal (CS#) asserted low followed by the assertion of the MEMR#or the MEMW#. Once the CS# signal is recognized, an output signal(IOCHRDY#) is asserted to acknowledge the CS#. One skilled in the artwill appreciate that that the IOCHRDY# performs the same function as theWAIT# with respect to FIGS. 4 and 5.

[0050] Still referring to FIG. 7, the IOCHRDY# is asserted until validdata is ready to be driven onto the bus for a read cycle or when datahas been successfully received for a write cycle. The bus cycle can belengthened by the IOCHRDY#. The configuration of the byte select signalsBE0#-BE3#, in conjunction with MEMR# and MEMW#, with reference to FIG.6, determines if the data bus bits are driven, i.e., a read operation,or sampled, i.e., a write operation. Once the CPU clock sees theIOCHRDY# deasserted, the CS# and the command signals (BE0#-BE3# andMEMR# or MEMW#) are deasserted to end the bus cycle. The address usedfor the bus cycle is sampled once after the start condition (CS# drivenlow) is recognized. Address bits A0 and A1 of the 21 bits of addressspace are not used in the bus interface in one embodiment since the byteenable signals determine the lower address bits. It will be apparent toone skilled in the art that the bus interface described with respect toFIGS. 6 and 7 is not capable of interfacing with as broad a variety ofCPUs as the bus interface described with respect to FIGS. 3-5. The setof command signals associated with FIGS. 3-5 allows the bus interface tocommunicate with a broader range of CPUs. However, it should beappreciated that the command signals for both of the above referencedinterfaces allows for on command modifiable reads. That is, for a 32 bitbus an 8, 16, or 32 bit read can be performed.

[0051]FIG. 8 is a table representing the bus interface timing parametersassociated with FIG. 7. The timing parameters of FIG. 8 correlate withthe timing parameters of FIG. 5. Of course, the command signalsassociated with FIG. 5 and the command signals associated with FIG. 7are different. That is, the set of command signals associated with FIG.5 are configured to indicate a read operation or write operation and alocation of valid data on the bus. Furthermore, each of the commandsignals of FIG. 5 are configured to concurrently define read or writeenable data as discussed with respect to FIG. 3. On the other hand, thecommand signals associated with FIG. 8 include separate sets of signalsto define if the bus cycle is a read or write operation and the locationof valid data on the bus.

[0052]FIG. 9 is a table illustrating the command signal encoding for anasynchronous generic bus interface that determines whether the currentbus cycle is a read or a write cycle and the location of valid data onthe bus in accordance with one embodiment of the invention. The commandsignals of FIG. 9 are all active low. A chip select signal (CS#) isdriven low to indicate that the LCD controller has been selected. Aread/write control signal (R/W#) is used to indicate whether a readcycle or a write cycle is to be performed. Driving the RW# signal highindicates a read cycle will be performed, while driving the RW# lowindicates a write cycle will be performed. It should be appreciated thatthe R/W# is not related to the determination of which parts of the databus contain valid data. That is, the R/W# does not include enable datacorresponding to the data associated with the read operation or thewrite operation. Four byte select signals (ByteSeln#) are used tospecify which bytes of a 32 bit data bus contains valid data. Thus, an 8bit, 16 bit or 32 bit read bus cycle or write bus cycle can be specifiedas indicated by the various combinations of ByteSel0#-ByteSel3#.

[0053]FIG. 10 is a timing diagram of an asynchronous generic businterface of a display controller configured to support any differencein clock speed between the display controller and a CPU in communicationwith the display controller in accordance with one embodiment of theinvention. A bus cycle initiates with CS#, also referred to as arequest, asserted low by the bus master, i.e., CPU. After this startcondition is recognized, the bus slave, i.e., LCD controller,acknowledges the request by asserting the WAIT#, referred to asacknowledge. The WAIT# is asserted until valid data is ready to bedriven onto the bus for a read cycle or when data has been successfullyreceived for a write cycle. Of course, the R/W# determines if the accessis a read operation or a write operation and the configuration ofByteSel0#-ByteSel3# define which data bus bits are driven or sampled.After the bus master sees WAIT# deasserted, the bus master will deassertthe CS# and the command signals. The address used for the bus cycle issampled once after the start condition is recognized. It should beappreciated that address bits A0 and A1 are not used in the businterface in one embodiment since the byte select signals determine thelower address bits.

[0054] Still referring to FIG. 10, an exemplary read operation will beexplained. Bus clock (BCLK) is the clock controlling the bus master,i.e., CPU, while LCD BCLK is the clock controlling the bus slave, i.e.,display controller, such as a LCD controller. As an exemplaryillustration, the LCD controller includes 21 bits of address space, asrepresented by A[20:0], which determines the amount of memory within theLCD controller. As mentioned above, the LCD controller is not limited to21 bits of address space as the amount of address space can vary. In oneembodiment, the LCD controller has about 2 Megabytes (MB) of memory.That is, 21 bits of address space maps out to about 2 MB of memory. Thememory inside the LCD controller is addressed through address linesA[20:0]. One skilled in the art will appreciate that the LCD controllercan contain any amount of memory suitable for the system containing theLCD controller and is not limited to 2 MB of memory. Memory/Registersignal (M/R#) is a signal that selects between memory (M) and registers(R) of the LCD controller. In one embodiment, an additional 2 MB ofmemory is provided through the M/R# pin. As mentioned above, the memorycore contains image data to be presented while the registers includeconfiguration data. It should be appreciated that the asynchronous businterface is truly asynchronous as the timing of the signals to the businterface from the LCD controller are controlled by the LCD clock. Thatis, the signals to the bus interface from the LCD controller areindependent of the CPU clock. As a result, the signals from the LCDcontroller are not slaved to a single CPU clock or oscillator, thusdefining a truly asynchronous bus interface.

[0055] The CPU requests the cycle from the LCD controller by assertingCS# low. The LCD controller responds to the request with an acknowledgesignal, i.e., WAIT#. It should be appreciated that the request andacknowledge signals are the two handshaking signals used to initiate abus cycle. Furthermore, while the CPU issues the request according tothe CPU clock, the LCD controller samples the request at the clock speedof the LCD controller. That is, the LCD controller is sampling therequest on the rising edge of the LCD BCLK, which is independent of theBCLK for the CPU. Of course, the LCD controller can sample on thefalling edge of the LCD BCLK also. Timing parameter t3 represents thetime period between the LCD controller sampling CS# low and assertingWAIT# to acknowledge to the CPU that a sample is being requested. Theacknowledge signal starts the bus cycle for the LCD controller. It willbe apparent to one skilled in the art that t3 is variable depending onthe speeds of the CPU and the LCD controller. The CPU then responds witha R/W# indicating a read or a write operation and ByteSel0#-ByteSel3#indicating the location of valid data on the data bus.

[0056] For a read cycle, with reference to FIG. 10, timing parameter t5represents the time period within which the LCD controller will drivethe data bus. Dark envelope 140 indicates that the LCD controller isdriving the data bus, thereby preventing another controller from takingover the bus. The dark envelopes of FIG. 10 represent that valid data isnot available while the light envelopes represent that valid data isavailable. Thus, valid read data becomes available at some point withinlight envelope 142. Timing parameters t8 and t9 represent the set uptime and hold time, respectively, similar to timing parameters t16 andt13 of FIG. 4. The end of the internal cycle for the LCD controlleroccurs when the WAIT# is deasserted, i.e., WAIT# goes high, which isperformed by the LCD controller according to the LCD BCLK. Thereafter,the CPU will see the WAIT# go high when the CPU samples the WAIT# on therising edge of the BCLK and will acknowledge back to the LCD controllerby deasserting CS#. Thus, the bus cycle is completed from the CPU side.Here, a similar handshaking procedure occurs to end the cycle as thehandshaking procedure that initiates the cycle, with the exception thatthe LCD controller issues a request by asserting WAIT# high and the CPUacknowledges the request by asserting CS# high. It should be appreciatedthat timing parameter t9 defines a hold time after the CS# has gone highin order to guarantee that data is available for the CPU to sample thatdata. Arrow 144 indicates the WAIT# being driven high by the LCDcontroller and the high WAIT# being recognized by the CPU which in turndrives the CS# high. It should be appreciated that the WAIT# is drivenaccording to the clock of the LCD controller and is not synchronous tothe CPU clock, thereby allowing the bus interface to run at any clockspeed, i.e., independent of the CPU's clock speed. Once the LCDcontroller sees the CS# go high the LCD controller releases the bus bydriving WAIT# to a high impedance state as indicated by arrow 146.

[0057] Still referring to FIG. 10, a write operation follows a similarhandshaking method as the read operation. Timing parameter t4 defines aset up period within which the CPU must drive the data on the data bus,while timing parameter t7 is a hold time defining a time period for datato be held after the LCD controller is ready to receive the data, i.e.,the WAIT# is driven high. It should be appreciated that timingparameters t4 and t7 are similar to timing parameter t7 and t12,respectively, of FIG. 4. In order to minimize the possibility of anymetastability conditions occurring, two flip flops in series areprovided within the circuitry of the LCD controller for receiving thecommand signals, such as M/R# and the command signals of FIG. 9, i.e.,CS#, R/W#, and ByteSeln#. Thus, the flip flops in series allow fordouble sampling of the command signals. That is, the command signals areprocessed through at least two flip flops connected in series tominimize a metastable condition.

[0058]FIG. 11 is a table representing the asynchronous bus interfacetiming parameters of FIG. 10. Timing parameters t3-t5 and t7-t9 havebeen discussed above with reference to FIG. 10. Timing parameter t1defines a setup time. Thus, parameter t1 allows a time period for CS# togo low. Timing parameter t2 indicates a setup time for LCD BCLK to seeCS# go low. Parameter t6 indicates a time period required to keep thecurrent cycle active, i.e., CS# low, after the CPU deasserts the commandsignals. The minimum time for parameter is zero nanoseconds (ns),however, one skilled in the art will appreciate that most CPUs do notdeassert CS# until one or two clocks after the command signals aredeasserted.

[0059]FIG. 12 is a schematic diagram of flip flop chain redundancycircuitry configured to minimize the occurrence of any metastablecondition in accordance with one embodiment of the invention. Flip flop150 is arranged in series with flip flop 152. Clock 154 is the displaycontroller clock, as flip flops 150 and 152 are contained within thecircuitry of the bus interface of the display controller. Signal 156 isthe D input of flip flop 150. The data present at the D input of flipflop 150 is transferred to the Q output of flip flop 150. The Q outputof flip flop 150 is then provided as the D input of flip flop 154. The Dinput of flip flop 154 is transferred to the Q output of flip flop 152where it is output as output signal 158. Thus, should input signal 156change during the set up time, a metastable condition may occur. Forexample, with respect to an asynchronous bus interface, the rising edgeof the bus clock and the display controller clock may occur at about thesame instant, resulting in two infinite slopes causing a metastablecondition. One skilled in the art will appreciate that if a metastablecondition occurs and the output from flip flop 150 floats, i.e. is not a0 or 1, the circuitry within flip flop 152 is configured to output a 0or a 1 depending on the level at which the output from flip flop 150floats. It should be appreciated that while two flip flops are shown inFIG. 12, any number of flip flops arranged in series could be used. Inone embodiment, the flip flop chain redundancy circuitry is configuredto process the command signals and not the read or write data.

[0060]FIG. 13 is a flowchart diagram illustrating the method operationsfor communicating between a display controller operating at a firstclock speed and a microprocessor operating at a second clock speed inaccordance with one embodiment of the invention. The flowchart initiateswith method operation 170 where a request from a microprocessor isreceived. The request is achieved by the microprocessor driving CS# lowand thus starts the bus cycle for the microprocessor. As mentioned aboveCS# being driven low indicates that the display controller is beingselected. As the request is issued by the microprocessor, the request isgenerated at the clock speed of the microprocessor. The method thenadvances to operation 172 where the request is sampled according to adisplay controller clock. Here, a display controller, such as a LCDcontroller, samples the request as discussed above with reference toFIG. 10. It should be noted that the microprocessor clock and thedisplay controller clock can operate at any difference in clock speed.In one embodiment, the CPU and the microprocessor are part of anembedded system for a handheld computing device.

[0061] The method of FIG. 13 then proceeds to operation 174 where therequest from the microprocessor is acknowledged to initiate an internalcycle of the display controller. For example, the initiation of theinternal cycle of the display controller is illustrated by the region ofthe timing diagram of FIG. 10 where WAIT# is driven low. The displaycontroller sends the acknowledgement, therefore, the acknowledgement isgenerated according to the clock of the display controller. Thus, thebus interface can be run at any clock speed independent of the CPU's busspeed.

[0062] Still referring to FIG. 13, the method proceeds to operation 176where data associated with a read or a write operation is provided. Thedata is provided to the microprocessor for a read operation, while thedata is provided to the display controller for a write operation. Theparameters of the read or write operation are discussed above withrespect to FIG. 10. The method then moves to operation 178 where thedisplay controller issues a request to end the internal cycle. In oneembodiment, the request is performed by driving WAIT# high asillustrated with respect to FIG. 10. Of course, the request is issued atthe clock speed of the display controller. The method then advances tooperation 180 where an acknowledgment from the microprocessor isreceived by the display controller. The microprocessor samples therequest from operation 180 at the clock speed of the microprocessor, andin response drives CS# high (the acknowledgement) as illustrated withreference to FIG. 10. The display controller then samples CS# high (theacknowledgement) at the clock speed of the display controller. As aresult of the CS# driven high, the microprocessor ends themicroprocessor bus cycle.

[0063] With the above embodiments in mind, it should be understood thatthe invention may employ various computer-implemented operationsinvolving data stored in computer systems. These operations are thoserequiring physical manipulation of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated. Further, the manipulationsperformed are often referred to in terms, such as producing,identifying, determining, or comparing.

[0064] Any of the operations described herein that form part of theinvention are useful machine operations. The invention also relates to adevice or an apparatus for performing these operations. The apparatusmay be specially constructed for the required purposes, or it may be ageneral purpose computer selectively activated or configured by acomputer program stored in the computer. In particular, various generalpurpose machines may be used with computer programs written inaccordance with the teachings herein, or it may be more convenient toconstruct a more specialized apparatus to perform the requiredoperations.

[0065] The above described invention may be practiced with othercomputer system configurations including hand-held devices,microprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers and the like. Althoughthe foregoing invention has been described in some detail for purposesof clarity of understanding, it will be apparent from the foregoingdescription that certain changes and modifications may be practicedwithin the scope of the appended claims. Accordingly, the presentembodiments are to be considered as illustrative and not-.restrictive,and the invention is not to be limited to the details given herein, butmay be modified within the scope and equivalents of the appended claims.

1. A display controller configured to communicate with a microprocessor;the display controller comprising: a memory core for storing image datato be displayed; a register set containing configuration data enablingpresentation of the image data; and a bus interface enablingcommunication over a bus between the memory core of the displaycontroller and the microprocessor, the bus interface being configured tocommunicate with a set of command signals, the set of command signalsdefines both whether read operations and write operations are to occurover a bus cycle and whether valid data exists for each bit of the readoperation and the write operation, wherein each command signal in theset of command signals defines enable data for one of the readoperations and write operations.
 2. The display controller of claim 1,wherein the command signals are configured to specify a location of thevalid data on the bus for one of an 8-bit read operation, a 16-bit readoperation and a 32 bit read operation.
 3. The display controller ofclaim 1, wherein the set of command signals is defined by a subset ofwrite enable signals and a subset of read enable signals.
 4. The displaycontroller of claim 3, wherein the subset of write enable signals isdefined by four write enable bits.
 5. The display controller of claim 3,wherein the subset of read enable signals is defined by four read enablebits.
 6. The display controller of claim 4, wherein the four writeenable bits are WE0#, WE1#, WE2#, and WE3#.
 7. The display controller ofclaim 5, wherein the four read enable bits are RD0#, RD1#, RD2#, andRD3#.
 8. The display controller of claim 3, wherein when each writeenable signal is a logical high value indicates the read operation. 9.The display controller of claim 3, wherein when each read enable signalis a logical high value indicates the write operation.
 10. A system acentral processing unit (CPU); a data bus; a display controller incommunication with the CPU through the data bus, the display controllerincluding a bus interface to enable communication over the data bus withthe CPU, the bus interface being configured to communicate with a set ofcommand signals, the set of command signals defines both whether readoperations and write operations are to occur over a bus cycle andwhether valid data exists for each bit of the read operation and thewrite operation, wherein each command signal in the set of commandsignals defines enable data for one of the read operations and writeoperations.
 11. The system of claim 10, wherein the command signals areconfigured to specify a location of the valid data on the bus for one ofan 8-bit read operation, a 16-bit read operation and a 32 bit readoperation.
 12. The system of claim 10, wherein the set of commandsignals is defined by a subset of write enable signals and a subset ofread enable signals.
 13. The system of claim 12, wherein the subset ofwrite enable signals is defined by four write enable bits.
 14. Thesystem of claim 12, wherein the subset of read enable signals is definedby four read enable bits.
 15. The system of claim 13, wherein the fourwrite enable bits are WE0#, WE1#, WE2#, and WE3#.
 16. The system ofclaim 14, wherein the four read enable bits are RD0#, RD1#, RD2#, andRD3#.
 17. The system of claim 10, wherein the display controllerincludes 21 bits of address space.
 18. A method for performing a readoperation or a write operation between a microprocessor and a displaycontroller, the method comprising: defining a set of command signalsconfigured to indicate whether the read operation or the write operationis to be performed over a bus cycle and whether valid data exists foreach bit of the read operation and the write operation, wherein eachcommand signal in the set of command signals defines enable data for oneof the read operation and the write operation; selecting a displaycontroller in communication with a system bus; asserting the set ofcommand signals; sampling the asserted set of command signals todetermine a type of operation and a bit-location of valid data on thesystem bus; selecting the bit location of the system bus having thevalid data; and performing the read operation or the write operation.19. The method of claim 18, wherein the command signals are configuredto specify a location of the valid data on the bus for one of an 8-bitread operation, a 16-bit read operation and a 32 bit read operation. 20.The method of claim 18, further including: defining set up and holdtimes for accommodating a propagation delay.
 21. The method of claim 18,wherein the method operation of sampling the asserted set of commandsignals to determine a type of operation and a bit-location of validdata on the system bus, further includes: extending the bus cycle untilvalid data is available.
 22. The method of claim 21, wherein the methodoperation of extending the bus cycle until valid data is available,further includes: driving a WAIT# signal low.
 23. A method for adaptinga display controller to communicate with a variety of microprocessors,the method comprising: receiving a chip select signal; acknowledging thechip select signal; receiving a set of command signals configured toindicate whether the read operation or the write operation is to beperformed over a bus cycle and whether valid data exists for each bit ofthe read operation and the write operation, wherein each command signalin the set of command signals defines enable data for one of the readoperations and write operations; and performing the read or the writeoperation for the valid data as defined by the command signals.
 24. Themethod of claim 23, further including: defining set up and hold timesfor accommodating a propagation delay.
 25. The method of claim 23,wherein the set of command signals is defined by a subset of four writeenable signals and a subset of four read enable signals.
 26. The methodof claim 25, wherein the four write enable signals are defined by writeenable bits WE0#, WE1#, WE2#, and WE3#.
 27. The method of claim 25,wherein the four read enable signals are defined by read enable bitsRD0#, RD1#, RD2#, and RD3#.
 28. The method of claim 23, wherein themethod operation of performing the read or the write operation for thevalid data as defined by the command signals further includes: extendingthe bus cycle until valid data is available.
 29. The method of claim 28,wherein the bus cycle is extended by driving a WAIT# signal low.